home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 672 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.7 KB
  1. Subject: Re: two bugs fixed in ramfs 1.4 
  2. Date: Mon, 29 Nov 93 17:03:40 PST
  3. From: Howard Chu <hyc@hanauma.jpl.nasa.gov>
  4.  
  5.  
  6. Howdy, all...
  7.  
  8.   Hello Evan,
  9.   
  10.   > ========================  quote =======================
  11.   > You should apply the following patch to ramfs.c to upgrade it from
  12.   > version 1.4 to version 1.5.  It fixes these two bugs.
  13.   > =======================================================
  14.   > 
  15.   > I believe there is another bug.  STZIP Fseek's to the end of the
  16.   > file to read the header information at the end.  STZIP is not able
  17.   > to read the header information from any file on RAM FS.  I believe
  18.   > its a problem of RAMFS.
  19.   
  20.   increasing the debug level in MiNT reveals that stzip issues a
  21.   
  22.       Fseek(-2048,2) on handle 6
  23.       
  24.   which should hopefully put the pointer 2048 bytes before the end of the
  25.   file.  The problem is of course: should the offset really be negative? I
  26.   have two books about Gemdos which give two different answers to this
  27.   simple question -- probably Murphy's law. 
  28.   
  29.   Most of the device drivers existing for MiNT (procfs.c, shmfs.c,
  30.   clockdev.c) assume that Fseek(offset,handle,2) will put the pointer
  31.   "offset" bytes _before_ the end of the file.  Therefore, "offset" should
  32.   be positive.  Ramfs also follows this convention.  Minixfs probably
  33.   follows the opposite convention, since it works with stzip. 
  34.   
  35.   [ We could make the program more bomb-proof by considering only the
  36.   absolute magnitude of "offset"; but in ramfs you should also be able to
  37.   seek past the end of a file, so it's not desirable. ]
  38.  
  39. Well, lseek in Unix says the offset is added to the specified position
  40. (beginning, current, end), so this would seem to be a pervasive bug.
  41.  
  42.